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METHOD FOR IMPLEMENTING POLYINSTANTIATED ACCESS 
CONTROL IN COMPUTER OPERATING SYSTEMS 



BACKGROUND OF THE INVENTION 
5 This invention relates to the field of control of access to services available 

through computer operating systems. More particularly the invention relates to control of 
access to services available through multilevel secure systems wherein a multilevel secure 
operating system implements mandatory access control and maintains security labels. 

In the past, computer operating systems have relied on a plurality of 

10 gatekeepers, often called "daemons," to monitor all requests and to control access to 
services. These computer operating systems have thereby allowed decentralization of 
many management functions and related security functions. While often beneficial, such 
decentralization can jeopardize system security, integrity, and consistency. Complexity 
of design and implementation and uncoordinated decentralized management can lead to 

1 5 inconsistency and compromises in security. 

These inconsistencies in general computer operating systems are of even 
greater concern in multilevel secure operating systems. Complexity of design and 
implementation is greater in these multilevel secure operating systems, and decentralized 
management of security policies leads to potential compromise of information under 

20 protection of these systems. Furthermore, in multilevel secure operating systems, these 
gatekeepers have provided more than the gatekeeping functions by maintaining session 
contexts, maintaining user security label information, and allowing access to services 
available at multiple security labels. In multilevel secure operating systems these 
implementations are often inefficient, leading to high processing overhead. Thus, in 

25 multilevel secure operating systems, distributed access management through multiple 
autonomous gatekeepers controlling access at multiple security labels is a reason for 
concern. 

SUMMARY OF THE INVENTION 
According to the invention, a master daemon (a dedicated program 
30 component) is provided for a computer operating system which utilizes selected criteria to 
perform actions in one or more domains, as defined hereinafter. The master daemon 
provides application program interfaces (APIs or facilities) and monitors all requests (for 
which the master daemon is configured) directed to the associated computing base 
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including the operating system. All requests are in the form of encapsulated information, 
as defined hereinafter. In general, the master daemon, in response to such requests, 
performs the actions, each constrained to operate exclusively in a single domain. 
Selected criteria that may be contained in at least one of the header information, trailer 
5 information and payload information may define a higher-order multidimensional domain 
space for segregating system operational functionality according to configured 
boundaries. Multiple instances of actions may exist simultaneously in the same domain 
in the associated computing base, with the master daemon performing the actions for each 
request as required in each selected domain. 

10 According to a specific embodiment of the invention, as prompted by 

limitations in a purportedly multilevel secure operating system normally directly 
responsive to autonomous daemons, security is improved through an augmentation 
applied to the operating system in the form of a master daemon and operative according 
to a method for controlling access to domains. More specifically, a domain may be 

1 5 configured using constructs, as defined hereinafter, of security labels and other criteria. 

In other embodiments of the invention, the master daemon may utilize 
criteria other than or in addition to the security label of the request. For example and in 
particular when used in operating systems that do not provide security labels, the master 
daemon may utilize one or more criteria, as hereinafter defined, individually or in 

20 combinations. To assure maximum integrity, at least one criteria should be in an 

unmodifiable or unspoofable portion of the request. For purposes of this discussion 
unmodifiable (and/or unspoofable) suggests that the fields are initialized or maintained by 
facilities under the control of the computing base and generally not modifiable by user 
processes. The invention is thus useful for processing a wide variety of requests. 

25 The invention will be better understood by reference to the following 

detailed description in conjunction with the following drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Figure 1 is a block diagram of elements of a polyinstantiated access 
30 control enhanced operating system (PACEOS) according to the invention. 

Figure 2 is a control flow chart illustrating the function of a master 
daemon according to the invention. 

Figure 3 is a data flow chart illustrating information flow of an initial 
request in a system according to the invention. 
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Figure 4 is a data flow chart illustrating information flow of initial and 
subsequent requests in a system with respect to instantiating a subdaemon. 

Figure 5 is a data flow chart illustrating information flow of initial and 
subsequent requests in a system with respect to instantiating a subprocess. 
5 Figure 6 is a data flow chart illustrating information flow of initial and 

subsequent requests in a system with respect to instantiating a subthread. 

Figure 7 is a data flow chart illustrating information flow of control 
requests and control responses. 

1 0 DESCRIPTION OF SPECIFIC EMBODIMENTS 

In order to better understand the invention, the following explanation is 
provided, including a glossary of selected terms. 

GLOSSARY OF TERMS 
Action: As used herein, an action is an operation performed on, by, or on 
1 5 behalf of a local or a remote computing base. Examples of actions include but are not 
limited to operations such as executing an instruction, directly responding to a request, 
instantiating a process, instantiating a daemon, instantiating a thread, instantiating a task, 
instantiating a job, submitting a job to a queue, controlling a process, issuing a request, 
opening a device, closing a device, reading, writing, submitting a document to a printer 
20 for printing, initiating a connection or other communication channel, running a program, 
starting a device, stopping a device, controlling a device, enforcing access controls, 
selecting criteria. 

Application Program Interface (API): An API is a methodology by 
which an application program interfaces with a system, such as a master daemon, 
25 consisting of formalized software calls and routines that can be used to access underlying 
structures. 

Computing base: A computing base is a computer system including both 
the hardware and operating system software with all required peripheral devices and 
subsystems. A conventional computing base is a computing base using a conventional 
30 operating system. A trusted computing base is a computing base using a multilevel 
secure operating system. A trusted computing base is therefore an enhancement of a 
conventional computing base. 

Construct: As used herein, a construct is a mathematical concept derived 
from set theory. Examples of such constructs include but are not limited to various 
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structures that can be arranged for example (1) in a lattice, (2) as a non-contiguous set, (3) 
as an array, (4) as a range, (5) as a chain, (6) as a semigroup, (7) as a matrix, (8) as a 
string, (9) as a grammar, (10) as a topology, (1 1) as a function, (12) as a graph, (13) as a 
map, (14) as a coordinate system, (15) as a group, (16) by use of any of the 
5 aforementioned constructs or mathematical constructs or other mathematical constructs, 
(17) some combination of these structures, or (18) some combination of these structures 
on multiple elements. See also criteria, domain, orders of domains. 

Criteria (Criterion): As used herein, a single criteria is an identifiable 
segment of information that can be extracted or derived from encapsulated information. 

10 The encapsulated information may be in the form of one or more requests. When so 
defined, the criteria can be used in a configuration subsystem either individually or in 
combinations to further define other criteria. See also encapsulated information. 

Domain: As used herein, a domain is a space defined by one or more 
criteria or by one or more sets of criteria. This space is organizationally a set whose 

15 members consist of permitted and/or denied actions and permitted and/or denied access. 
Thus, the universal domain of the zeroth order is that domain which permits any and all 
actions and access to any and all objects, and the null domain is that domain which denies 
each and every action and denies access to each and every object. The criteria used to 
define a domain or domains may be specified in a configuration subsystem. Actions 

20 constrained to operate within a domain are implemented by a master daemon acting in a 
"superdomain." Note that standard set theoretic constructs also apply to domains, e.g., 
every domain is a subdomain of the universal domain of its order; every domain is a 
superdomain of itself; every domain is a subdomain of itself; and the null domain is a 
subdomain of every domain. Additionally, every domain must exist in at least one order 

25 of domains. Domains may themselves contain more restrictive subdomains (i.e. 
"dominated subdomains") defined by additional criteria derived from the initial or 
succeeding requests, which in turn may contain even more restrictive sub-subdomains, ad 
infinitum (to the limits defined by the configuration of the master daemon and the 
operating system). In a multilevel secure operating system, domains may be implemented 

30 by use of security labels in combination with zero or more additional criteria. Domains in 
multilevel secure operating systems need not correspond to a singular security label, but 
generally consist of sets of criteria, where the criteria include constructs of criteria as 
defined by the configuration of the master daemon. See also action, construct, criteria^ 



4 



dominate, lattice, null domain, orders of domains, partially ordered set, set, universal 
domain, zeroth order. 

Dominate, Dominance: The concept of dominance is similar to the 
concept of "greater than or equal to." For example, consider two domains A and B: 
5 domain A is said to "dominate" domain B if it incorporates at least all criteria in B. Note 
that two equal domains A and B each dominate the other. Alternatively, if domain B 
incorporates criteria not incorporated in domain A, then domain A does not dominate 
domain B. This does not imply that domain B dominates domain A, since the dominance 
relation includes the possibility of incomparable criteria. The dominance relation is used 
10 to define a partial ordering of criteria, hence the specific meaning of dominance must be 
specified for each configured type of criteria. See also lattice, null domain, universal 
domain. 

Encapsulated information: As used herein, encapsulated information 
consists of at least one of header information, trailer information and payload 
15 information. Examples of encapsulated information includes but is not limited to packets, 
cells, frames, other communication structures, files, information in an operating system 
that implements mandatory access control via the use of security labels on information, 
security labels, process, objects, messages, domains. See also request. 

Inf: An inf is the lowest ranking member of a lattice; also, the member of 
20 a lattice that is dominated by all other members of the lattice. Every lattice must have 
both a sup and an inf. See also lattice, sup. 

Lattice: A lattice is a partially ordered set having both an inf and a sup. 
See also inf partially ordered set, set, sup. 

Null action: A null action is a null operation, that is, an action that results 
25 in no action being performed. A null action may also be called an ignoring action. A null 
action is always one possible valid action. A null action may also be implemented by 
performing an action in the null domain. 

Null domain: A null domain is the domain whose bounds define a region 
that encompasses no space. The null domain is a subdomain of every domain. See also 
30 universal domain. 

Orders of domains: Every domain exists within an order, that order of 
domains being defined by a single set of criteria. By utilizing one or more other separate 
though possibly overlapping sets of criteria, it is possible to create multiple orders of 
domains. When multiple orders of domains are thus defined, it is useful to identify each 



as an Nth order domain, where N corresponds to the set number of the criteria utilized to 
define each order. Multiple orders can be viewed as a multidimensional system of 
coordinates, wherein a single domain appears representationally as a point in the 
potentially hyperspatial coordinate system. For example, in a system employing four 
5 orders of domains, a first order (also called highest order) domain might be defined by 
use of sets of security label criteria, a second order domain by use of sets of user 
identification criteria, a third order domain by use of sets of networking parameters, and a 
fourth order domain by use of sets of information-payload-based criteria. Orders can be 
overlapping or non-overlapping, completely encompassed by higher orders (thereby sub- 
10 orders), or not encompassed by other orders (independent orders). As a special case, 
every order of domains is a suborder of the zeroth order of domains. The orders of 
domains form a partially ordered set. See also construct, criteria, domain, partially 
ordered set, zeroth order. 

Partially ordered set (or partly ordered set, or poset): A poset is a set 
15 that includes members and defines a partial ordering relation, such as "dominates," on 

those members. A lattice is a special case of a partially ordered set which has both an inf 
and a sup. See also, inf, lattice, sup. 

Request: As used herein, a request is encapsulated information processed 
by a computing base. A request must include all of the encapsulated information. See 

20 also encapsulated information. 

Security label: A security label is a security identifier assigned to an 
object based on the level at which the object is to be protected. Objects to which security 
labels may be applied are identifiable elements of a computing base, such as but not 
limited to information stores, files, disks, devices, computing bases, operating systems, 
25 peripheral devices, processes, users, roles, user accounts, data packets, memory locations, 
input devices, output devices, and control structures. Security labels aid in implementing 
a layer of functionality known as mandatory access control, which exists in addition to 
other access control functionality. 

Set: A set is a mathematical concept for a prescribed collection of points, 
30 numbers, or other objects that satisfy a given condition, or that satisfy specific criteria. 

Subdomain: A subdomain is a domain that is completely bounded by 
another domain. Every domain is a subdomain of itself, every domain is a subdomain of 
the universal domain of its order, and the null domain is a subdomain of every domain. 
See also domain, dominate, null domain, set. 



Sup: A sup is the highest ranking member of a lattice. Also, the member 
of a lattice that dominates all other members of the lattice. Every lattice must have both a 
sup and an inf. See also inf lattice. 

Superdomain: A superdomain is a domain that completely bounds 
5 another domain. Every domain is a superdomain of itself, and the universal domain is a 
superdomain of every domain of its order. See also domain, dominate, set, universal 
domain. 

Universal domain: A universal domain is the domain whose bounds 
define a region that encompasses all possible domain space in any given order of 
10 domains. Every domain is a subdomain (or a dominated domain) of the universal domain 
of its order. Equivalently, the universal domain is a superdomain (or a dominating 
domain) of every domain of its order. See also domain, dominate, null domain, orders of 
domains, set, subdomain, superdomain. 

Zeroth order: The zeroth order is the highest order of domains, the order 
15 of domains that encompasses all possible universal domains, and dominates all possible 
sub-orders. See also orders of domains. 



Figure 1 is a block diagram illustrating the elements of a polyinstantiated 
access control enhanced operating system (PACEOS) 10 according to the invention 

20 supporting a plurality of operational domains, the bounds of which are defined by at least 
one criteria, and possibly bounded to a finer granularity by additional criteria. In the 
specific case where the conventional computing base 12 is a trusted computing base, the 
criteria include security labels. The PACEOS 10 comprises a conventional computing 
base (CCB) 12 including a hardware component 14, its base operating system 16 which 

25 may include among other things the functionality of access control, networking, 

processing and data encapsulation. In a specific case where the base operating system 16 
is a multilevel secure operating system, the access control function also implements 
mandatory access control. The hardware component 14 and the base operating system 16 
include for example control functions of central processing units [CPU(s)], peripheral 

30 storage, input/output devices, input/output subsystems [I/O subsystem(s)], network 
device(s) and memory (not shown). 

According to the invention, a Master Daemon (MD) 18, controls access to 
services provided by the PACEOS 10. Other processes 20 may optionally have access to 
the base operating system 1 6 without intervention of the MD 18. The MD 18 is 
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configured according to its configuration subsystem 22 to intervene and respond to 
selected types of requests to the PACEOS 10. The configuration subsystem 22 may have 
its origin in configuration information which is stored locally, remotely, or centrally. In 
its operation according to the invention and in response to configured types of requests, 
5 the MD 1 8 performs actions that may include, for example, instantiation of subordinate 
daemons also called subdaemons 24 for the purpose of carrying out the action or actions. 
Importantly, according to the invention the subdaemons do not have authorization to 
control other subdaemons in non-dominated domains. However, a subdaemon may 
instantiate other subdaemons, granting control and access to the other subdaemons within 

10 its limits of authority, or more genetically, within the limits of its domain. In this way, 
subdaemons are used to securely isolate processes of the base operating system 16, 
whether or not in the context of a multilevel secure operating system. Further in 
operation according to the invention and in response to designated types of requests, the 
MD 1 8 performs actions that may include, for example, instantiation of subordinate 

1 5 processes also called subprocesses 26 for the purpose of carrying out the responses to the 
requests. Various actions can perform other actions within their domain or more limited 
subdomains. 

Referring to Figure 2 the control process that might be implemented by a 
master daemon or MD 18 is illustrated. First the MD 18 self certifies the operational 

20 environment to determine whether the environment is valid (Step A). If the environment 
is found not to be valid, the MD 18 is terminated (Step B). 

If the environment is found to be valid, the MD 18 initializes its 
operational policies from its configuration subsystem 22 (Step C), then it initializes itself 
to listen for requests for which it is to monitor and act (Step D), and then it waits for 

25 requests (Step E). In response to a request, the MD 18 examines the request (Step F), 
selects the appropriate domain to be used in the succeeding action or actions (Step G) 
thereby limiting the action or actions strictly to that domain and its dominated 
subdomains, and then selects the appropriate action or actions (Step H). An action may 
be, for example, instantiating one or more subdaemons (Step I), or instantiating one or 

30 more subprocesses (Step J), or instantiating one or more lightweight processes (also 
called subthreads) within the MD 18 (Step K), or performing any other defined action 
(Step L), or ignoring the request (Step M), or any combination or sequence of these 
actions. Then the MD 18 performs housekeeping functions (Step N) including restoring 
its original domain if necessary, and reverts to waiting for further requests (Step E). 



Among the control of actions are at least one of the following: auditing, initiation, 
initialization, instantiation, termination, monitoring, status reporting, interruption, 
suspension, continuation, prioritization, and possibly others. The MD 18 may provide an 
appropriate user interface, 
5 In order to better understand the invention, it is helpful to understand the 

API of a master daemon and actions associated with a master daemon. These interface 
descriptions make reference to Figures 1, 3, 4, 5, 6, and 7. 
Master Daemon (MD 18) API 

The API for the master daemon (or MD 1 8) may provide facilities to 

10 extend capabilities of the base operating system 16 and to ease implementation of 

daemons, subdaemons, processes, subprocesses, subthreads, and other actions (hereinafter 
"subordinates" or "actions"). Precise means of implementing subordinates will vary 
depending upon the choice of base operating system 16, but the general method for 
interfacing with any subordinate is the same. In all cases, interface is via the master 

15 daemon which accepts the first request 21 for each service for which it has been 

configured to provide an action. Ignoring a request is also a valid action (i.e. a null action 
is one possible valid action). The first request 21 is analyzed according to the configured 
criteria and utilized to select a domain from the multiplicity of higher orders of domains. 
The master daemon then selects one or more actions in response to the request (and 

20 possibly its succeeding requests if part of a series of requests), and constrains all such 
actions to operate exclusively within the selected domain or within some subdomain that 
is dominated by the selected domain. If processing the request requires instantiation or 
performance of a subordinate or subordinates, then upon instantiation or performance of 
subordinate(s), the MD 18 passes the first request 21 to the subordinate(s). Passing the 

25 first request 21 to subordinate(s) may be achieved through any means of data transfer 
provided by the base operating system 1 6, including but not limited to command line 
arguments, environment arguments, environment variables, shared memory structures, 
files, memory, registers, queues, interprocess communication facilities, file system stores, 
network interfaces, protocols, streams devices, input/output devices, function calls, 

30 procedure calls, messaging, or any other such means as may be available. After 

successfully transferring the first request 21, the MD 18 returns to listening for new first 
requests 21, while the subordinate(s) continue handling subsequent requests 42 (if any). 
Subordinate Daemon Interface 
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The subordinate daemon (or subdaemon 31) implements the method 
specified by the MD 18 for receiving the first request 21 from the MD 18 for daemon- 
provided services. Subsequent requests 42 are then handled directly by the subdaemon 
3 1 . The subdaemon 3 1 is neither limited nor restricted from handling additional requests 
5 that may involve the performance of additional actions that then become a new generation 
of subordinate(s) to this subdaemon 31. A subdaemon 31 may thus itself be a new master 
daemon acting in the same or more limited domain than its instantiating master daemon. 
This relationship is transitive through subordinate actions, meaning that it is possible to 
create hierarchies of master daemons, each constrained to operate in the same or a more 

10 limited domain than its immediate predecessor. This hierarchy can itself be viewed as a 
poset, with the most venerable master daemon occupying the position of the sup of the 
poset of master daemons (and possibly other interrelated actions) thereby created. 
Subordinate Process Interface 

The subordinate process (or subprocess 33) implements the method 

15 specified by the MD 18 for receiving the first request 21 from the MD 1 8 for process- 
provided services. Subsequent requests 42 are then handled directly by the subprocess 
33. The subprocess 33 is neither limited nor restricted from handling additional requests 
that may involve the performance of additional actions that then become a new generation 
of subordinate(s) to this subprocess 33. A subprocess 33 may thus itself be a new master 

20 daemon acting in the same or a more limited domain than its instantiating master daemon. 
This relationship is transitive through subordinate actions, meaning that it is possible to 
create hierarchies of master daemons, each constrained to operate in the same or a more 
limited domain than its immediate predecessor. This hierarchy can itself be viewed as a 
poset, with the most venerable master daemon occupying the position of the sup of the 

25 poset of master daemons (and possibly other interrelated actions) thereby created. 

A subprocess 33 differs from a subdaemon 31 in that the former is 
typically used to provide one or more special purpose services to a single user, whereas 
the latter is typically used to provide general purpose services to one or more users 
according to varying criteria, and also that the latter generally continues to act until 

30 administratively terminated. Note that this is a loose definition of these terms, and not a 
requirement that in any way affects the constraints on either subdaemons 3 1 or 
subprocesses 33 as to their ability to perform actions on single or multiple requests for 
single or multiple users. 
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Subordinate Thread Interface 

The master daemon or MD 18 may instantiate subordinate threads or 
subthreads 35 to handle certain requests. The choice of using a subthread rather than 

5 instantiating a subdaemon 31 or subprocess 33 is guided by availability and efficiency of 
features of the base operating system 16. For those actions which are implemented by 
using a subthread 35, the subthread 35 implements the method specified by the MD 18 for 
receiving the first request 21 from the MD 18 for thread provided services. Subsequent 
requests 42 are then handled directly by the subthread 35. The subthread 35 is neither 

1 0 limited nor restricted from handling additional requests that may involve the performance 
of additional actions that then become a new generation of subordinate(s) to this 
subthread 35. A subthread 35 may thus itself be a new master daemon acting in the same 
or a more limited domain than its instantiating master daemon. This relationship is 
transitive through subordinate actions, meaning that it is possible to create hierarchies of 

1 5 master daemons, each constrained to operate in the same or a more limited domain than 
its immediate predecessor. This hierarchy can itself be viewed as a poset, with the most 
venerable master daemon occupying the position of the sup of the poset of master 
daemons (and possibly other interrelated actions) thereby created. 
Control API 

20 The master daemon (or MD 1 8) control API may be implemented internal 

to the MD 18 so that it does not require external interfaces other than those provided by 
the base operating system 16. A user interface may enhance the usability of the MD 18 
control subsystem, but such user interface is not required. 

Figure 3 is a data flow diagram of a system utilizing a master daemon (the 

25 MD 18). In the diagram, a client system 19 (which may be operating on the same CCB 
12 as the MD 18, or may be operating on a different computing base that has some 
method of exchanging requests, for example via a network, with the conventional 
computing base 12 on which the MD 18 is located) transmits a request 21 to the MD 18. 
A selector 27 chooses one or more of several possible actions (Steps 31, 33, 35, 37), or it 

30 may choose to ignore the request 21 (Step 39). 

The flow of information depicting the first and subsequent requests with 
respect to each of the actions is more fully described in succeeding figures. Information 
flow with respect to instantiating a subdaemon 31 is described in more detail in Figure 4. 
Information flow with respect to instantiating a subprocess 33 is described in more detail 



in Figure 5. Information flow with respect to instantiating a subthread 35 is described in 
more detail in Figure 6. Information flow with respect to performing control actions is 
described in more detail in Figure 7, which is one of many possible other actions that may 
be implemented by the MD 18. Performance of actions other than those shown in Figures 
5 4 through 7 is also possible, but not shown in any figure. 

In Figure 4, requests 21, 42 flow from a client 19 to the I/O subsystem 17 
of the PACEOS 10. The first request 21 is passed to the MD 18, wherein an element 26 
examines the first request 21 preliminary to selection. A selector 27 shows only the 
selection of instantiating a subdaemon 3 1, the other potential selections being omitted for 
10 purpose of clarity. Subsequent requests 42 are passed directly from the I/O subsystem 17 
of the PACEOS 10 to the subdaemon 31. The subdaemon 31 generates responses 41 for 
the first request 21 and for the subsequent requests 42. These responses 41 flow back out 
through the I/O subsystem 17 of the PACEOS 10, thence onward as responses 41 to the 
client 19. 

15 In Figure 5, requests 21 flow from a client 19 to the I/O subsystem 17 of 

the PACEOS 10. The first request 21 is passed to the MD 18, wherein an element 26 
examines the first request 21 preliminary to selection. A selector 27 shows only the 
selection of instantiating a subprocess 33, the other potential selections being omitted for 
purpose of clarity. Subsequent requests 42 are passed directly from the I/O subsystem 1 7 

20 of the PACEOS 10 to the subprocess 33. The subprocess 33 generates responses 41 for 
the first request 21 and for the subsequent requests 42. These responses 41 flow back out 
through the I/O subsystem 17 of the PACEOS 10, thence onward as responses 41 to the 
client 19. 

In Figure 6, requests 21 flow from a client 19 to the I/O subsystem 17 of 
25 the PACEOS 10. The first request 21 is passed to the MD 18, wherein an element 26 
examines the first request 21 preliminary to selection. A selector 27 shows only the 
selection of instantiating a subthread 35, the other potential selections being omitted for 
purpose of clarity. Subsequent requests 42 are passed directly from the I/O subsystem 17 
of the PACEOS 10 to the subthread 35. The subthread 35 generates responses 41 for the 
30 first request 21 and for the subsequent requests 42, These responses 41 flow back out 
through the I/O subsystem 17 of the PACEOS 10, thence onward as responses 41 to the 
client 19. 

In Figure 7, control requests 71 flow from a client 19 to the I/O subsystem 
17 of the PACEOS 10 and are passed through to the MD 18. In this figure, the MD 18 



processes control requests 71 directly, although this action could alternatively be 
implemented in the MD control subthread (not shown). For all control requests 71 the 
MD 18 generates control responses 72 which flow to the I/O subsystem 17 of the 
PACEOS 10, flowing thence to the client 19. Control responses may incorporate 
5 information as to the status of the requested control action. 

In each instance, the daemons, subdaemons, processes, subprocesses, 
subthreads and other actions can perform actions all of which are bounded by the same or 
more restrictive subdomains than the domain of their instantiator. 

While not explicitly shown in the figures, the system is designed to operate 
10 on multiple clients and on multiple systems, including actions involved with utilizing a 
master daemon on one system that performs actions that may be carried out on remote 
systems, and including performance of both local and remote actions. 

In a multilevel secure operating system which enforces mandatory access 
control, this invention retains existing security mechanisms and enhances the security of 
1 5 applications operating on the multilevel secure operating system. 

The invention has been explained with respect to specific embodiments. 
Other embodiments will be evident to those of ordinary skill in the art. It is therefore not 
intended that this invention will be limited, except as indicated by the appended claims. 
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WHAT IS CLAIMED IS: 



1 1 . In an operating system on a computing system wherein requests are 

2 in the form of encapsulated information, a method for controlling access to actions and 

3 objects within the computing system, said computing system providing facilities for the 

4 instantiation of said objects and performance of said actions, said method comprising: 

5 configuring selected domains on said computing system as configured 



6 domains, each one of said configured domains comprising a higher-order 

7 multidimensional domain space, for segregating system operational functionality 

8 according to defined operational boundaries, said operational boundaries defined by 

9 mapping attributes of the requests into individual domains; 



10 providing a master daemon, said master daemon selecting said configured 

1 1 domains by utilizing said attributes of the requests; 

12 causing said master daemon to respond to selected ones of said requests to 

13 perform at least one of the following actions on said computing system: 

14 instantiating on said operating system at least one 

1 5 subordinate daemon; 

16 instantiating on said operating system at least one 

1 7 subordinate process; 

18 instantiating on said operating system at least one 

1 9 subordinate thread; 

20 performing at least one other defined action; 

21 wherein said subordinate daemons, said subordinate processes, said 

22 subordinate threads, and said other defined actions being constrained to operate within 

23 one of said configured domains at least as restrictive as the configured domain of said 

24 master daemon. 

1 2. The method according to claim 1 , wherein said master daemon is 

2 further operative to: 
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3 control functionality of all said instantiated subordinate daemons, 

4 subordinate processes, subordinate threads and said defined actions on said operating 

5 system in said computer system. 

1 3. In an operating system on a computing system according to claim 

2 1 , wherein said master daemon is further operative to: 

3 interface with said computing system to maintain centralized and 

4 coordinated access to auditing subsystems of said operating system. 

1 4. The method according to claims 1-3 wherein said selected domains 

2 are further defined by at least one of a security label, a set of security labels, a lattice of 

3 security labels, a group of security labels, a range of security labels, a combination of 

4 collections of security labels, and other defined constructs. 

1 5. In an operating system on a computing system connected to a 



2 network of computing systems wherein requests are in the form of encapsulated 

3 information, a method for controlling access to actions and objects within any of the 

4 computing systems, said computing systems providing facilities for the remote 

5 instantiation of said objects and performance of said actions, said method comprising: 



6 configuring selected domains on at least one of said computing systems as 

7 configured domains, each one of said configured domains comprising a higher-order 

8 multidimensional domain space for segregating system operational functionality 

9 according to defined operational boundaries, said operational boundaries defined by 

10 mapping attributes of the requests into individual operating domains; 

1 1 providing a master daemon, said master daemon selecting said configured 

12 domains by utilizing said attributes of the requests; 

1 3 causing said master daemon to respond to selected ones of said requests to 

14 perform at least one of the following actions on at least one of said computing systems: 

1 5 instantiating at least one daemon; 

16 instantiating at least one subordinate daemon; 

17 instantiating at least one process; 
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1 8 instantiating at least one subordinate process; 

1 9 instantiating at least one subordinate thread; 

20 performing at least one other defined action; 

21 wherein said daemons, said subordinate daemons, said 

22 processes, said subordinate processes, said subordinate threads, and said 

23 other defined actions being constrained to operate within one of said 

24 configured domains at least as restrictive as the configured domain of said 

25 master daemon. 

1 6. The method according to claim 5 wherein at least one of said 

2 computing systems is local to said master daemon. 

1 7. The method according to claim 6 wherein at least one of said 

2 computing systems is on said network and is remote from said master daemon. 

1 8. The method according to claim 5 wherein at least one of said 

2 computing systems is on said network and is remote from said master daemon. 

1 9. The method according to claim 8 further including the step of: 

2 causing said master daemon to respond to selected ones of said requests to 

3 perform a defined action on said remote computing system. 

1 10. The method according to claim 9, wherein said master daemon is 

2 further operative to: 

3 control functionality of all said instantiated daemons, subordinate 

4 daemons, processes, subordinate processes, subordinate threads and said defined actions 

5 on selected ones of said operating systems on computer systems connected to said 

6 network. 

1 1 1 . In an operating system on a computing system connected to a 

2 network of computing systems according to claim 10, wherein said master daemon is 

3 further operative to: 
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4 interface with said local computing system and said remote computing 

5 systems to maintain centralized and coordinated access to auditing subsystems of said 

6 computing systems connected to said network of computing systems. 

1 12, The method according to claims 5-11 wherein said selected 

2 domains are further defined by at least one of a security label, a set of security labels, a 

3 lattice of security labels, a group of security labels, a range of security labels, a 

4 combination of collections of security labels, and other defined constructs. 
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METHOD FOR IMPLEMENTING POLYINSTANTIATED ACCESS 
CONTROL IN COMPUTER OPERATING SYSTEMS 

ABSTRACT OF THE DISCLOSURE 

A master daemon (a dedicated program component) is provided for a 
computer operating system which utilizes selected criteria to perform actions in one or 
more domains, as defined. The master daemon provides application program interfaces 
(APIs or facilities) and monitors all requests (for which the master daemon is configured) 
directed to the associated computing base including the operating system. All requests 
are in the form of encapsulated information as defined. In general, the master daemon, in 
response to such requests, performs the actions, each constrained to operate exclusively in 
a single domain. Selected criteria that may be contained in encapsulated information may 
define a higher-order multidimensional domain space for segregating system operational 
functionality according to configured boundaries. Multiple instances of actions may exist 
simultaneously in the same domain in the associated computing base, with the master 
daemon performing the actions for each request as required in each selected domain. 
According to a specific embodiment, as prompted by limitations in a purportedly 
multilevel secure operating system normally directly responsive to autonomous daemons, 
security is improved through an augmentation applied to the operating system in the form 
of a master daemon and operative according to a method for controlling access to 
domains. More specifically, a domain may be configured using constructs of security 
labels and other criteria. 

PA 3075170 vl:KRA:dim 



18 



o 

© 

ui 
m 

m 
m 
o 

a 
m 
a 

g 

a 



CO 
O 

2 
a. 



O 



<D 
on 
co 

<D 
O 

2 
■§ 

GO 



GO 

a 
o 

S 
■9 

00 



a 




o 
"5 


stem 




>% 

CO 








■s 


o 


co 


U 





t/3 

>^ 
co 
too 
c 

■ 1—1 
(D 

O 

a> 

CO 



id 



OX 



TT 00 NO 










alize 


tiona 


cies 


Initi; 


opera 


poli 



Attorney Docket No.: 20570-1.00US 



DECLARATION AND POWER OF ATTORNEY 

As a below named inventor, I declare that: 

My residence, post office address and citizenship are as stated below next to my name; I believe I am the original, first and sole 
inventor (if only one name is listed below) or an original, first and joint inventor (if plural inventors are named below) of the subject 
matter which is claimed and for which a patent is sought on the invention entitled: METHOD FOR IMPLEMENTING 
POLYINSTANTIATED ACCESS CONTROL IN COMPUTER OPERATING SYSTEMS the specification of which JL is 
attached hereto. 

I have reviewed and understand the contents of the above identified specification, including the claims, as amended by any 
amendment referred to above. I acknowledge the duty to disclose information which is material to patentability as defined in Title 37, 
Code of Federal Regulations, Section 1.56. I claim foreign priority benefits under Title 35, United States Code, Section 119 of any 
foreign application(s) for patent or inventor's certificate listed below and have also identified below any foreign application for patent 
or inventor's certificate having a filing date before that of the application on which priority is claimed. 

POWER OF ATTORNEY: As a named inventor, I hereby appoint the following attorney(s) and/or agent(s) to prosecute this 
application and transact all business in the Patent and Trademark Office connected therewith. 

Kenneth R. Allen, Reg. No. 27,301 
1 David N. Slone, Reg. No. 28,572 



Send Correspondence to: 
Kenneth R. Allen 

TOWNSEND and TOWNSEND and CREW LLP 

Two Embarcadero Center, 8 th Floor 

San Francisco, California 94111-3834 



Direct Telephone Calls to: 

(Name, Reg. No., Telephone No.) 
Name: Kenneth R. Allen 

Reg. No.: 27,301 
Telephone: 650-326-2400 



Full Name of 


Last Name: 


First Name: 


Middle Name or Initial: 


Inventor 1: 


Bourgeois, III 


Fred 


J. 




Residence & 
Citizenship: 


City: 

Felton 


State/Foreign Country: 
California 


Country of Citizenship: 
United States 


Post Office 
Address: 


Post Office Address: 
150 Quail Glen 


City: 
Felton 


State/Country: 
California 


Postal Code: 
95018 



1 1 further declare that all statements made herein of my own knowledge are true and that all statements made on information and belief 
# are believed to be true; and further that these statements were made with the knowledge that willful false statements and the like so 

made are punishable by fine or imprisonment, or both, under Section 1 00 1 of Title 1 8 of the United States Code, and that such willful 

false statements may jeopardize the validity of the application or any patent issuing thereon. 




PA 3075153 v1 



lofl 



